Date: Tue, 20 Apr 93 04:30:02 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #107 

To: packet-radio 


Packet-Radio Digest Tue, 20 Apr 93 Volume 93 : Issue 107 


Today's Topics: 
(none) 
Info on PackeTexrm 
Internet port on packet 
method for improving packet thruput in noisy channels (well, maybe) (4 msgs) 
PTM522WW.ZIP - Danish Packet Terminal & Mailbox - Multi-ling. 
rec.radio.amateur reorg: current/evolving proposal 4/17 
Single chip receiver for FSK? 
Special Event Station "Memphis Belle" "W4BS" 
WANTED: TCM3105 chips, small quantities 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 19 Apr 93 17:40:01 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: (none) 

To: packet-radio@ucsd.edu 


I am working on a problem of scheduling classroom, and I will like to know if 
you have some software, papers or articles about it. If you have something 
relate it, please let me know. 


thanks 


Lorenza Illanes 


Date: 19 Apr 93 13:00:00 MDT 

From: usc!sdd.hp.com! portal! lhaven.UUmh.Ab.Ca!Lawrence_Chen@network.UCSD.EDU 
Subject: Info on PackeTerm 

To: packet-radio@ucsd.edu 


Hello Amiga Packet people. 


I'm looking to break into Packet myself....and I was reading through CQ, 
and saw an ad for PackeTerm. 


Has anybody out there used this program? If so, can they post or send me a 
quick review of the product? 


I'd also like pointers to other Packet related products for the Amiga. 


aTdHvAaNnKcSe 


-- Via DLG Pro v0.995 


"Just a Crazy Engineer with an Amiga and an HP48sx" - The Dreamer 
Email: dreamer@lhaven.uumh.ab.ca or "Lawrence Chen" @ 1:134/3002 

PHONE: +1 403 526 6019 FAX: +1 403 529 5102 CIS: 74200,2431 
Lunatic Haven BBS (1:134/3002): +1 403 526 6957 (14,400 HST/v.32bis) 
Lunatic Haven BBS (UUCP): +1 403 526 5035 (Telebit Worldblazer) 
Praxis Society K12 BBS (1:134/3003): +1 403 529 1610 (Telebit T2500SA) 


Date: Mon, 19 Apr 1993 22:40:45 GMT 

From: agate! howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu! 
ux1.cso.uiuc.edu!news.cso.uiuc.edu!ux4.cso.uiuc.edu!apeters2@ames.arpa 
Subject: Internet port on packet 

To: packet-radio@ucsd.edu 


I think the subject line says it all. Is there a 
way to get into internet or any other worldwide or 
nation-wide "land-line type" net? 


Avram 
n9oni 
apeters2@ux4.cso.uiuc.edu 


Date: Mon, 19 Apr 1993 16:48:49 GMT 
From: kgw2!NewsWatcher!user@uunet.uu.net 


Subject: method for improving packet thruput in noisy channels (well, maybe) 
To: packet-radio@ucsd.edu 


In article <1993Apr19 .033253.18601@cbfsb.cb.att.com>, 
wa2ise@cbnewsb.cb.att.com (robert.f£.casey) wrote: 


Better packet reception 


How about this method for improving packet reception (probably has been 
done, but here goes anyway). Sometimes, when noise causes a few errors 

in a received packet, the CRC rejects the packet and tells the transmitting 
station to resend it. If the noise persists, you are in for a lot of 
retries, and thruput is bad. Let's say, for example, that the received 
packets have about 5 errors. 


Suppose the receiving TNC stores the bad packet. and if the next try is 
also bad, store it. And if the third try is also bad, you could compare 
all three, byte by byte, and look for where they differ. 


VV VVV VV VV VV VV WV 


If the error rate is relatively low, you probably don't need to get the 
third try. Just create a third packet, trying data from both of the faulty 
packets until the CRC checks out. 


Dave Steele 

Xetron Corp. 

40 W. Crescentville Road 
Cincinnati, Ohio 45246 


Date: Mon, 19 Apr 1993 15:53:40 GMT 

From: usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!rsiatl!ke4zv! 
gary@network.UCSD.EDU 

Subject: method for improving packet thruput in noisy channels (well, maybe) 
To: packet-radio@ucsd.edu 


In article <1993Apr19 .033253.18601@cbfsb.cb.att.com> wa2ise@cbnewsb.cb.att.com 
(robert.£.casey) writes: 

> 

>Better packet reception 

> 

>Suppose the receiving TNC stores the bad packet. and if the next try is 
>also bad, store it. And if the third try is also bad, you could compare 

>all three, byte by byte, and look for where they differ. Errors should 
[delete] 


>Don't know if this is usually done ("Don't you know that this is called 
>'digital blah blah ba blah', anyone who had ‘Packet 101 knows that!"), or maybe 
>the extra s/n margin this would buy is too small to be worth the trouble? 

>It's just some more code in the TNC's EPROM, and a little more use of 
>scratchpad RAM, which room probably exists already without increasing 

>parts count or cost. Just an increase of the time for someone to write it. 
>(No, I don't have the programming skills to try this myself, unfortunately). 


This *xisx a familiar approach. It fails when the packets aren't framed 
correctly, which unfortunately is very common on the noisey channel. 

This will shift the relative byte positions one or more bits left or 
right. This makes the comparison impossible unless you have the horsepower 
to do shift and compares across the length of the packets. This is one of 
those n4n computational problems. It xis* simple in that it will work with 
ordinary packet stations, but it doesn't work often enough to be robust. 


A much stronger system that uses a different version of FEC is 
computationally possible. Bit errors tend to come in batches 

due to the nature of the channel, so if you arrange the packet 

so that adjacent bits aren't transmitted in sequence you can 
"smear" the error out in such a way that simple error correcting 
codes can reconstruct it. To do this you prepare the packet by 
reading it into the rows of a matrix, attaching a simple Reed 
Solomon FEC to the end of each row. You then read the data out 
for transmission by columns, attaching a RS FEC to the end of 
each column. On receive you read the data back into a matrix 

by columns, do the FEC calculations, repair damaged bits, and 

read the reconstructed packet out by rows. Though this sounds 
more complex, the computational requirements are less, log(n), 
than the misframed case for the other method. It does require both 
stations to cooperate in using the method. This is the method 

used in digital video recorders to deal with "dropouts" in the 
magnetic media, similar to RF noise bursts. It's amazingly robust. 
The FEC adds some overhead, but since resends become rare, it's 
thruput is better. 


In pure gaussian noise, a soft decision bit slicer can enhance 
operations even more, but it fails to be useful in the presense 
of strong non-gaussian interference. 


Gary 

Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory!kd4nc!ke4zv! gary 


Date: Mon, 19 Apr 93 19:14:12 GMT 

From: gumby!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!adec23! 
mark@yale.arpa 

Subject: method for improving packet thruput in noisy channels (well, maybe) 

To: packet-radio@ucsd.edu 


wa2ise@cbnewsb.cb.att.com (robert.f£.casey) writes: 


>Better packet reception 

Sa ae 4 

>Suppose the receiving TNC stores the bad packet. and if the next try is 
>also bad, store it. 


FEC of a form. I would even go simpler than that, I would take xanyx 
differences and try them all (why look just for pairs that match). The only 
(slight) problem is that you are increasing the chances of receiving a packet 
full of errors as if it was correct (Data wrong, CRC sez not). There are 

also cases of bit slipping too (loose a bit) that could get your mind 
wandering. 


I did something like this with passall-on and let the confuser reconstruct 
traffic on the channel from the ascii streams. I did xnot* see any improvement 
of copy (and I took a performance hit on the box as it was slow already), but 
that is probably due to the fact I was monitoring rather than being an active 
participant (and the fact I did not have access to the CRC) 


Now, the ‘technical' problem. The TNC has NO idea what the CRC is, since 
the Synchronous UART strips that off before presenting it to the CPU. It is 
possible to tell the UART to not do the CRC stuff, but that is a big change 
to the software operation of the TNC (Any Z-80 based TNC). I believe the 
KAM's processor has good access to the CRC, but with their support, and 

our lack of source code ... 


Ok, who is going to add this to their KISS firmware first? 


Ciao, 73 de VE6MGS/Mark -sk- 


Date: Mon, 19 Apr 93 23:00:57 GMT 

From: usc!howland.reston.ans.net!usenet.ins.cwru.edu!agate!news.ucdavis.edu! 
csus.edu!netcom.com!netcomsv!orchard.la.locus.com!prodnet.la.locus.com! 
lando.la.locus.com!dana@network.UCSD.EDU 

Subject: method for improving packet thruput in noisy channels (well, maybe) 
To: packet-radio@ucsd.edu 


In article <daves-190493124744@129.228.20.182> daves@xetron.com (Dave Steele) 


writes: 

>In article <1993Apr19 .033253.18601@cbfsb.cb.att.com>, 
>wa2ise@cbnewsb.cb.att.com (robert.f£.casey) wrote: 

>> 

>> 

>> Better packet reception 

>> 

>> How about this method for improving packet reception (probably has been 
>> done, but here goes anyway). Sometimes, when noise causes a few errors 


>> in a received packet, the CRC rejects the packet and tells the transmitting 


>> station to resend it. If the noise persists, you are in for a lot of 
>> retries, and thruput is bad. Let's say, for example, that the received 
>> packets have about 5 errors. 


>> Suppose the receiving TNC stores the bad packet. and if the next try is 
>> also bad, store it. And if the third try is also bad, you could compare 
>> all three, byte by byte, and look for where they differ. 


>If the error rate is relatively low, you probably don't need to get the 
>third try. Just create a third packet, trying data from both of the faulty 
>packets until the CRC checks out. 

> 


It really depends how strong the CRC is. You could easily get an erroneous 
packet which checks out against the CRC. Furthermore, the kinds of errors 
you get may cause the receiver to lose sync with the incoming data and 

not receive anything at all until it sees another flag. You can't just 
store a fragmented piece of a packet without a lot of special effort. 


FEC packet would work more easily with less magic; you just program your 
TNC to send every packet twice. Heck, rather than using a long TXD you 
could a very short TXD and send the packet twice. The TX Delay time is 
simply wasted time to let someone's receiver warm up. Sending the 
packet twice would give slow receivers a chance to warm up and give 

the quick receivers (i.e. people using DCD State Machines) two chances 
at reading a noisy a packet.... 


Dana 

x Dana H. Myers KK6JQ | Views expressed here are x 

* (310) 337-5136 | mine and do not necessarily * 

* dana@locus.com DoD #466 | reflect those of my employer 
*k 


x This Extra supports the abolition of the 13 and 20 WPM tests x 


Date: Tue, 20 Apr 1993 07:02:14 GMT 

From: tacom-emh1.army.mil!msdos-ann-request@uunet.uu.net 

Subject: PTM522WW.ZIP - Danish Packet Terminal & Mailbox - Multi-ling. 
To: packet-radio@ucsd.edu 


I have uploaded to WSMR-SIMTEL20.Army.Mil and OAK.Oakland.Edu: 


pd1:<msdos.packet> 
PTM522WW.ZIP Danish Packet Terminal & Mailbox - Multi-ling. 


PTM Packet Terminal V 5.22 is a Danish Packet Terminal and Mailbox. 

At the moment PTM is able to talk Danish, Swedish, Norwegian, English, 
Italian, Spanish, French, German and Russian. It supports several 
modems: TNC2c, PK-88, PK-232, KAM 2.85, KAM 5.02, and TNC241. The 
mailbox will default to english, but give the user an option to change 
the language to be used. 


The PTM Mailbox does support file uploads and downloads, and many other 
features. 


The program can be used with no limitations, but the author asks users 
to register - Read the following section of the documentation: 


If you do not register your copy at once the only consequence 
is that PTM will flash a reminder for 30 sec's before starting 
up. There are no other limitations in the program. 


Per Holm - ph@fi.aau.dk 

Internet: ph@fi.aau.dk 

X.400: C=dk; ADMD=dk400; PRMD=minerva; O=aau; OU=fi; S=ph 
FidoNet: Per_Holm@2:230/22 

HamNet: Pexr_Holm@12: 210/107 

EEggNet: Per_Holm@97:9451/4 


Date: Mon, 19 Apr 93 15:21:53 GMT 

From: usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!sol.ctr.columbia.edu! 
destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!adec23! 
mark@network.UCSD.EDU 

Subject: rec.radio.amateur reorg: current/evolving proposal 4/17 

To: packet-radio@ucsd.edu 


ikluft@uts.amdahl.com (Ian Kluft) writes: 


>rec.radio.amateur.rdf radio direction finding: recreational 
> hunts and searches for interference 
>rec.radio.amateur.antenna discussion of amateur radio antennas 


There is the act of rdfing and then there is the equipment. equipment will 
grey area into .antenna or .equipment AND .rdf. (Not a 
disagreement with the proposal, just half hearted support :-) 


>rec.radio.amateur.operating Operating procedures and questions: DX, 
> CW, contests, propagation, repeaters 

> alternatives proposed: r.r.a.dx and r.r.a.repeaters 

The .repeater group will degenerate (poor word!) I think into not much 
different than .policy discussions. I'd stick with .operating with a good 

short FAQ saying that .dx discussions are greatly welcomed (as the name 

could add confusion for the .dxers, but much of what they will say WILL 

be salient to operating procedures). 


>Issues currently under discussion 


>The following issues and notes relate to the discussions listed above: 

>*x a place for beginners to ask their typically-unfocused questions 

> suggestions: r.r.a.beginner (markz/jbloom/emd) 

> concerns: r.r.a.instruction allows enough room for license upgrades as well 
> and r.r.a.beginner will have the same questions repeatedly (pschleck/ 

> ikluft/jgt10/kevin) 

If I was a newbie on both USENET and Amateur Radio, I'd go to .misc first. 

I am not sure we can focus beginners into any specific group, and once they 
are less green under the collar, participation drops off quickly. 


> results so far: only the name is in dispute, beginner or instruction will 
> be on the CFV. r.r.a.instruction is slightly ahead - can everyone live 
> with it? 

.instruction since it encompasses more. 


> results so far: only the definition is in dispute, dx or operating of some 
> sort will be on the CFV. r.r.a.dx and r.r.a.operating seem to ruffle the 
> fewest feathers - can everyone live with them? 

I'd be saddened to see the .dx crowd not imparting their operating procedure 
know how ;-) , but yes, this proposal (I don't support the split of this group, 
but this split sounds the best). 


> To break the deadlock: can you live with r.r.a.construction? If not, 

> should we roll up products/construction/technical and call them 

> r.r.a.equipment? (That seems to fit the theme everyone is arguing over.) 
I rest (what, you think you have worn me out! :-) and support .equipment 


as the meta for products/construction/technical/tech/homebrew/.shack (<---hmmm) 


What do you mean the nntp link is down <shaking feverishly> -- 73 de VE6MGS/Mark 


Date: 19 Apr 93 11:40:49 GMT 

From: pipex!uknet!acorn! agodwin@uunet.uu.net 
Subject: Single chip receiver for FSK? 

To: packet-radio@ucsd.edu 


In article <C5LOxM.E25@law7.DaytonOH.NCR.COM> jra@law7.DaytonOH.NCR.COM (John 
Ackermann x 2966) writes: 


>My goal is to come up with an inexpensive design for a receiver "back 
>end" with IF input on one end and an FSK demondulator on the other. I'm 
>particularly interested in ways to use a higher IF than 10.7 -- do any 
>current chips work up to, say 150MHz with internal downconversion so a 
>normal IF filter can be used? 

> 


GEC/Plessey specify a series of FM demodulators (SL1454 etc) for use in 
satellite TV receivers : 150 or 600MHz in, 10MHz of baseband video out. 

I think there's also a related data slicer / clock recovery circuit intended 
for use in DMAC decoders, though that isn't used in the most common 
implementation - it may not be in volume production. 


The most easily available components probably vary with local satellite 
standards, and I think the european systems vary rather widely from those 
in the US - so it may be worth investigating locally-available receiver 
designs to find out what's in common use. 


-adrian 


Adrian Godwin : agodwin@acorn.co.uk : adrian@fangorn.demon.co.uk : g7hwn@gb7khw 
ObDisclaimer : I believe this rubbish .. don't imagine that anyone else does. 


Date: 19 Apr 93 17:42:46 GMT 

From: sdd.hp.com! zaphod.mps.ohio-state.edu!caen!destroyer!cs.ubc.ca!alberta!ugc! 
nebulus! ve6mgs ! rec-radio-info@network.UCSD.EDU 

Subject: Special Event Station "Memphis Belle" "W4BS" 

To: packet-radio@ucsd.edu 


The Delta Amateur Radio Club of Memphis, TN., will be hosting "W4BS" 
Special Event station to commemorate the 50th anniversary of the 25th and 
final mission flown by the world famous B-17 "MEMPHIS BELLE". The 25th 


Mission was flown on May 17, 1943. 


This special event will be from 1300Z, May 16th until 0100Z, May 17th. The 
transceivers will be set up in the pavilion next to the "BELLE" on Mud 
Island in Memphis, Tennessee. We will operate the following stations: 


2 Meters - 146.550 Mhz 
10 Meters - 28.455 Mhz 
15 Meters - 21.320 Mhz 
20 Meters - 14.305 Mhz 
Packett - 145.01 Mhz and on the Internet Converse (CH. 25) 


For an especially nice certificate send QSL with contact number and SASE 
to: 


MEMPHIS BELLE 

c/o DARC 

P.O. Box 16343 

Memphis, TN 38186-0343 
USA 


For more information, please contact: 
David Moore at: 
KD4CAC @ W4BS.#WESTN.TN.USA.NA 
kd4cac @ gate.n9gsa.ampr.org 


Suresh Kagoo EE Dept , Memphis State University 


| \/ | / JN | | | | Engineering 211 | Domain: KAGOOS@MEMSTVX1.MEMST .EDU 
1}\ / | \ec- \ I ILL | Memphis, TN 38152| AMPR : n9gsa@gate.n9gsa.ampr.org 
es N GE [Lib N22 os IN, Sree et / Ph: (901) 678-3867| AX.25 : NOGSA@W4BS.4#WESTN.TN.USA 


Date: 20 Apr 93 00:44:18 GMT 

From: pa.dec.com!e2big.mko.dec.com!dbased.nuo.dec.com!news.crl.dec.com! 
payne@decwrl.dec.com 

Subject: WANTED: 1TCM3105 chips, small quantities 

To: packet-radio@ucsd.edu 


Does anyone know if a source for the TCM3105 modem chips (as used in the 
Baycom and my PMP modems)? Ideally, something that is geared toward 
hobbyists: small quantity, mail order, etc. 


For years, we've been buying them from a distributor (Marshall) by the 
hundreds for PMP kits. But orders have dropped to the point where we can 
no longer afford to offer this service. And all of the distributors I've 
checked have some crazy minimum order ($100, or so). 


I'd like to find a source for those still interested in building PMP kits. 
Any suggestions? 


Andrew C. Payne 
DEC Cambridge Research Lab 


End of Packet-Radio Digest V93 #107 
KIKKIK KKK KK AK IKI K IKI K KI 


